Post not yet marked as solved
This text not an error message originated from APNs. APNs will return an error code and a short explanation of the problem.
So, the server must be seeing that and printing out this message. We would need to know what error APNs actually returns to understand what the problem is.
Post not yet marked as solved
Once you have successfully built and installed your app, properly configured with the necessary entitlements, you should be seeing the option to make that app the default app in Settings->General->Contactless & NFC
For this setting option to show up (or for any any of the EEA based features to work)
Your app must be correctly configured and built with the correct entitlements and the necessary APIs
Your testing device must physically be located in the EEA and is a supported type (iPhone only).
The signed-in Apple ID on the device must be registered in an EEA country or region.
While we would need to see the actual token to examine and see if there is problem with it, if you are seeing the simulator token to be the same length as a physical device, there could be a mistake when converting it. We expect the simulator tokens to be longer HEX strings. Make sure your code serializing the token data into a HEX string is not assuming a certain length.
The new CoreLocation APIs introduced in iOS 17 will solve that problem, as they will relaunch your app without relying on significant location change.
Discover streamlined location updates: https://developer.apple.com/videos/play/wwdc2023/10180/
Meet Core Location Monitor: https://developer.apple.com/videos/play/wwdc2023/10147/
Post not yet marked as solved
This is how things work. Apps will not be launched prior to the first unlock after a restart.
If they did, the apps would encounter a variety of problems as the file system would still be in a locked and encrypted state without the users entering their passcode first.
Post not yet marked as solved
The p8, as with any credentials should not be shared. How this will effect the lives of both parties will depend on the ongoing relationship between them.
First of all, who is going to be publishing the app. Is it you? In your name? Must be, if they don't have a developer account.
Many problems will arise:
do you have any other apps you are publishing on your own, or for other clients? Whomever holds the p8 will have the right and ability to send any kind of notifications to any of the apps you publish under your account. Do you trust them to not do this? Will you trust them in 5 years?
similarly for them, if you have a falling out, or even decide you are quitting development and will move to a small island to become a fisherman. What will they do? Once your account expires, the p8 is no good to them, and now they are stuck.
You asked for practical cases where this is a bad idea, and here they are.
The correct way for this to be done is for them to make a developer account, add you as a trusted Developer, so you can build the app under their account, and upload the app to App Store as such. You might need higher access to create App IDs, profiles, certificates and keys, etc., so they can either trust you to add as an Admin, or do it themselves with your guidance.
Post not yet marked as solved
You can check the status of APNs and any other Apple services at https://developer.apple.com/system-status/
Post marked as Apple Recommended
Hello all, as you may have realized by now, 17.4.1 has not fixed the problem you have been seeing.
I would like to first clarify what problem we are talking about, and for what problem we are recommending a workaround and waiting for a fix. The "problem" is twofold:
Starting with iOS 17.4 using CMAltimeter requires the declaration of NSMotionUsageDescription, authorization by the user, and have not turned off Fitness Tracking in settings:
This is not a bug. This is a permanent change per privacy requirements, and it is not going to go back to a state as before iOS 17.4, so you must change your app to include this privacy change.
Along with the above change, there was a behavior mismatch where if the app is only using CMAltimeter APIs like startRelativeAltitudeUpdates() in a simple pattern, this was not triggering the authorization prompt necessary for the altimeter data to be accessed. Apps that were already using other APIs that required this permission earlier, do not run into this issue.
This behavior is the one we are looking to change, where simply using CMAltimeter in a simple pattern will be enough to obtain the authorization. This change was not made in 17.4.1 but is being investigated for a future version.
To alleviate this, I had suggested a workaround using the CMPedometer API that was going to trigger the authorization prompt, after which apps only using CMAltimeter would work without issues. While that workaround we came up with quickly still works, we now have a better recommendation that does not require the use of another API, and we believe is more power efficient and has wider support of devices. The new recommended workaround is this:
func startAltitudeUpdatesViaMotionManager() {
self.motionActivityMotionManager.queryActivityStarting(from: .now, to: .now, to: .main) { _, _
in
self.altimeterManager.startRelativeAltitudeUpdates(to: .main) { altitudeData, error
// Handle altitude updates
}
}
}
If you call startRelativeAltitudeUpdates() using this pattern, this will solve the issue of the authorization prompt not appearing when using a more simple pattern. Also, this does not require the use of an unrelated and API which you would want to rush to remove from your code once a change is made to have the simple call patterns to trigger the authorization dialog.
In this case "deprecated" means that there is a replacement API, but this API has not been removed yet. If you look at the availability tags, it is still available in iOS 17.
You can still use the old APIs until they are no longer available.
If the replacement API is not providing the same functionality as before which have a use case for it, with no alternative ways of achieving that functionality, filing a Feedback Report on it as early as you can may be helpful.
This call is not available in visionOS. Considering none of the location APIs that require "Always" authorization to work at all are also not available in visionOS, what is the use case you have that needs this?
If you have a specific use case and would like this API to be considered for visionOS, you are welcome to file a Feedback report about it.
Post not yet marked as solved
HCE is now available on iOS 17.4, albeit only for banking and wallet apps in the European Economic Area running on an iPhone.
You can read the details here: https://developer.apple.com/support/hce-payment-transactions-in-payment-apps/
Developers will need to obtain a special entitlement, and the apps can only run (including for testing) on iPhones physically located in the EEA.
Post marked as Apple Recommended
The CoreMotion team is on the case, and is looking for a solution. But I am sure you would all appreciate that fixing and releasing a problem in an operating system is not a matter of a day or two.
I would like to thank everyone here who has been suggesting workarounds to get the authorization prompt to popup, which in turn enables CMAltimeter to start working.
That is indeed a good solution. Although, the API suggested here, CMSensorRecorder has a large power impact, and we do not recommend to use that as your temporary fix.
CMPedometer is not only less power hungry, but also has the widest availability on iOS versions and actual devices.
So, if you were to use
CMPedometer().queryPedometerData(from: Date(), to: Date()){ (data, error) -> Void in }
somewhere in your code as appropriate, this should temporarily solve your issue. @baraupp 's solution is a clean encapsulation, and could be used by replacing CMSensorRecorder calls with CMPedometer calls.
Also to confirm @baraupp 's findings, "Fitness Tracking" must indeed be turned on in Settings for the pedometer solution to work as well.
Post not yet marked as solved
What exactly do you mean by the "client" side? In BLE terminology, the client side is Central, and Server side is Peripheral.
visionOS supports BLE central apps so your app should run without any issues. If you mean the app is peripheral (using CBPeripheralManager), that is not supported on visionOS at this time.
If you would like the team to consider allowing peripheral apps on visionOS, they would appreciate if you could file a Feedback Report explaining your reasons, and how this would benefit your users. If you can share your Feedback ID here, it will be beneficial.
Post not yet marked as solved
If you stay within the "budget" on the device for each user, you will not have any rate limitation issues with sending push requests to APNs.
If you are worried about being rate limited due to the number of different users you will be sending live activity pushes to simultaneously, that is not a concern.
The per user "budget" is not documented, and could change. If you keep in mind that Live Activities are designed for occasional updates as needed, you should be OK.
You can read more here to determine your update frequency:
https://developer.apple.com/documentation/activitykit/starting-and-updating-live-activities-with-activitykit-push-notifications#Determine-the-update-frequency
Post not yet marked as solved
There is no such thing as "iOS uninstall data". Furthermore there is no such timing as this non-existent data appearing after the 8th day.
Wherever you may have obtained this information from must be confusing the Status/Error 410 (Unregistered) return to mean the app has been uninstalled.
The 410 status was never meant to be a signal for developers to determine that the app has been uninstalled. It is actually a signal to the push provider server that they should stop using that token. Although this could mean that the app may have been removed, it could also mean the token has changed while the app is still installed. The app token may change due to certain system events. Deleting and reinstalling the app, restoring the device from a backup, resetting the device (and then installing the app), certain major iOS updates, transferring all apps and data to a new device are all events that will cause the token to change. Because of this, it is recommended that apps register for remote notifications at every launch. If the token has changed, the app would need to update the push server to use the new token for the device/user. If an existing token is receiving 410, it might be that the app is still installed but one of these cases occurred.
Indeed if you look at the description of the 410 status, it says "The device token is no longer active for the topic.". Topic, in most cases means "your app". It is an indicator of the state of the token, not the app. And trying to determine whether an app has been deleted or not, based on the 410 result is an off-label use that would not guarantee the results you might expect. Additionally, beginning the return of the 410 state is non-deterministic for the sole purpose of discouraging this interpretation.
To summarize this interpretation: Existence of a 410 status merely indicates that the token is no longer valid and should not be used anymore. It does not mean the app has been deleted. Nor, the lack of a 410 status mean the app is still installed and receiving notifications. If it is important to your use case that you know notifications are being received, my suggestion would be to confirm the critical receipt of notifications via a service extension, or based on user interaction to indicate that the user has actually seen the notification, not just that the device has received it (for example, the phone sitting at bottom of a bag with mute switch on).
If you receive a 410 status for a token, you should stop using it. If you believe that the app has been removed but still receiving 200 status for the token, there is no harm in sending notifications to it until if and when you receive a 410.
